Secure money transfer techniques using hierarchical arrangement of smart cards

ABSTRACT

Systems and methods for providing secure smart card transactions are disclosed. Smart cards are arranged in a smart card hierarchy, the hierarchy including a first smart card at a first hierarchical level and a second smart card at a second hierarchical level higher than the first hierarchical level. A smart card reader is equipped to read smart cards and to accept personal identification (PIN) number inputs. According to one embodiment, a first PIN number is stored on the first smart card, the first PIN number corresponding to the first hierarchical level. A first security key is also stored on the first smart card. A second PIN number is stored on the second smart card, the second PIN number corresponding to the second hierarchical level. A second security key is stored on the second smart card. The PIN numbers and security keys are used to selectively lock and/or unlock a smart card.

This application is a continuation of application Ser. No. 08/546,056,filed on Oct. 20, 1995, now abandoned, which is a continuation-in-partof application, Ser. No. 08/194,186 filed Feb. 8, 1994, now issued U.S.Pat. No. 5,461,217 issued Oct. 24, 1995.

1. Technical Field

This invention relates generally to smart cards, and more particularlyto systems and methods for providing secure money transfers betweensmart cards and financial institutions.

2. Background of the Invention

Recent developmental efforts have been directed towards using smartcards as vehicles for the storage and transfer of money. Usingelectronic money in place of conventional bills and coins isadvantageous for several reasons. It is often cumbersome andinconvenient to carry around large amounts of money, notwithstanding theever-present risk of theft or loss. Bills and coins are expensive toproduce, and are subject to forgeries. Although some merchants mayaccept personal checks, the processing of these transactions oftenproves to be very time-consuming. In practice, existing checkverification procedures often involve a time delay sufficient to annoy,irritate, and/or frustrate customers who are waiting in line at themerchant's point-of-sale terminals.

With existing state-of-the-art technology, it is possible to use smartcards as devices on which to electronically store and transfer money.However, a system which does nothing more than electronically store andtransfer money is not practical for use in many real-world applications.As with any electronic data storage and a transfer system, securitybreaches are possible. If the concept of electronic money is ever to begenerally accepted, electronic money cannot be lost by the applicationproviders or by other participants such as merchants or customers.Although a certain amount of electronic money loss is acceptable andinevitable, these losses must be less than the current lossesexperienced with credit cards, cash, or checks. Prior-art electronicsecurity measures do not provide an electronic money system having therequisite level of security.

Existing smart card devices are not completely invulnerable to failure.For example, the smart card holder could forget to remove the smart cardfrom his or her pocket, and run the card through an entire washer/dryercycle, exposing the card to heat, mechanical vibrations, water, andchemically corrosive agents such as bleach and detergent, which couldresult in a smart card failure. Upon device failure, the hapless smartcard holder ends up losing the amount of money stored on the now-defunctcard. What is needed is a recovery technique applicable to smart cardsthat have become inoperable, so that the smart card holder does notsuffer a financial loss due to card failure.

Many state-of-the-art electronic financial transaction systems offerlittle or no customer privacy. This lack of privacy stems from the factthat current system architectures offer paid interest and/or protectionfor lost/stolen cards. As a result, those customers who desire privacymust pay in cash in order to attain transactional anonymity. Sinceconventional paper money offers virtual anonymity, the concept ofelectronic money should provide a similar degree of anonymity. At thevery least, an electronic system should provide anonymity upon request.

SUMMARY OF THE INVENTION

Systems and methods for providing secure smart card transactions aredisclosed. Smart cards are arranged in a smart card hierarchy, thehierarchy including a first smart card at a first hierarchical level anda second smart card at a second hierarchical level higher than the firsthierarchical level. A smart card reader is equipped to read smart cardsand to accept personal identification (PIN) number inputs. According toone embodiment, a first PIN number is stored on the first smart card,the first PIN number corresponding to the first hierarchical level. Afirst security key is also stored on the first smart card. A second PINnumber is stored on the second smart card, the second PIN numbercorresponding to the second hierarchical level. A second security key isstored on the second smart card. The PIN numbers and security keys areused to selectively lock and/or unlock a smart card.

BRIEF DESCRIPTION OF THE DRAWING

FIG. 1 is a block diagram showing a secure smart card money transfersystem;

FIG. 2 is a chart which describes a secure financial transaction betweentwo smart cards;

FIG. 3 is a flowchart which sets forth the operational sequence forimplementing a secure smart card financial transaction;

FIGS. 4A and 4B together comprise a flowchart which describes the stepsof a cardholder-to-cardholder transaction;

FIGS. 5A and 5B together comprise a flowchart which sets forth theprocedure for updating/changing security keys, and for adding interestto money stored on smart cards;

FIG. 6 is a block diagram showing the data structures which aretransferred from a first smart card to a second smart card during afinancial transaction;

FIG. 7 is a block diagram describing the data structures used by usersmart cards.

DETAILED DESCRIPTION

Techniques are disclosed for the secure transfer of a monetary value(herein after "money") between smart cards. These techniques alsoprovide for the secure transfer of a monetary value between anelectronic money vault and a smart card. This electronic money vaultincluding a processing device coupled to a data storage drive. Forexample, an electronic money vault may be implemented by a conventionalpersonal computer, by a mainframe computing device, by a smart card, orby any other hardware configuration that includes a microprocessor andmemory.

FIG. 1 is a block diagram setting forth hardware components and datastructures for a smart card secure money transfer system. In the exampleof FIG. 1, smart card 102 may represent the electronic money vault, itbeing understood that another type of electronic money vault could beused in place of smart card 102. For purposes of illustration, if amainframe computer was used to implement the electronic money vaultinstead of using smart card 102, this computer would be coupled to smartcard reader network 106 (described in greater detail hereinafter) usingtechniques well-known to those skilled in the art. The system of FIG. 1provides for adding interest payments to money stored on a smart card,and for checking the amount of money (account balance) stored on a smartcard. Activities such as the transfer of money between smart cards,adding interest payments to a smart card, and checking account balancesare referred to as financial transactions.

Smart cards 102, 104 are provided to a plurality of cardholders,including a first smart card 102 provided to a first cardholder and asecond smart card 104 provided to a second cardholder, each smart card102, 104 being capable of participating in one or more financialtransactions involving electronic money stored on the smart card. Ifsmart card 102 is used to implement the electronic money vault, then thefirst cardholder may be, for example, a bank, a merchant, or a consumer.Independent of the identity of the first cardholder, the secondcardholder may be blank, a merchant, or a consumer. If a cardholder is amerchant or a consumer, the smart card held by this cardholder isreferred to as a user smart card.

If a cardholder is a bank, the smart card provided to the bank is termeda bank smart card. Banks may be organized into a plurality of regions,each region consisting of one or more branch banks. In this situation,three subtypes of bank smart cards may be utilized, such as bank centersmart cards, bank region smart cards, and bank branch smart cards. Bankcenter smart cards are used to provide one or more electronic securitykeys to other smart cards, such as other bank smart cards, smart cardsheld by merchants, and/or smart cards held by consumers. These securitykeys may be updated (i.e., periodically changed) to allow and/or todisallow the transfer of money to/from a smart card. Note that banks atsome or all of the aforementioned hierarchical levels may use types ofelectronic money vaults other than smart cards, such as, for example,personal computers or mainframe computers, in place of the bank smartcard. Therefore, the following discussion of interest payments betweenbanks is applicable irrespective of whether the electronic money vaultsare implemented using smart cards or, for example, mainframe computers.

Bank center smart cards are used to provide interest payments to othersmart cards, such as to other bank smart cards and to user smart cards(cards held by merchants or consumers). Interest payments can beimplemented in a hierarchical manner with respect to a predefined smartcard hierarchy. For example, a bank center smart card may be employed toprovide interest payments to bank region smart cards. Similarly, thebank region smart cards may be used to provide interest payments to bankbranch smart cards, which, in turn, provide interest payments to smartcards held by consumers and merchants. Thus, the smart card hierarchy inthis example is structured such that a bank center smart card is at thetop of the hierarchy, followed by bank region smart cards and bankbranch smart cards. User smart cards are at the bottom of the hierarchy.The mechanics of interest payments will be described in greater detailhereinafter with reference to FIG. 1.

Each smart card 102, 104 contains the data structures and hardwareblocks described below in conjunction with FIG. 1, irrespective ofwhether the smart card is a user smart card or a bank smart card. In thecase where smart card 102 represents an electronic money vault, thensmart card 102 may actually represent any hardware configuration havinga processing device coupled to a data storage device. Irrespective ofwhether a smart card or some other type of hardware configuration isemployed for the electronic money vault, the security keys and securitykey storage registers described below are implemented, stored, andprocessed using a data storage device coupled to a processor. Therefore,even though the discussion below assumes that the electronic money vaultis smart card 102, this discussion is also applicable to the case wherea personal computer or a mainframe computer is used in place of smartcard 102 to implement electronic money vault.

Each smart card 102, 104 contains a security key storage register 112,128, respectively, for the storage of an electronic security key. Thesecurity key storage register 112, 128 may be provided in the form ofrandom-access memory (RAM). The security key register 112, 128 iscoupled to a security key register input device 118, 124, respectively,which is adapted to accept input from a smart card reader network 106.In this manner, an electronic security key may be transferred from thesmart card reader network 106 into the smart card security key storageregister 112. The security key register input device 118, 124 isequipped to accept input data in accordance with presently-existingsmart card data input/output (I/O) techniques well-known to thoseskilled in the art.

A security key register output device 114, 130 is coupled to thesecurity key storage register 112, 128, respectively. This output device114, 130 is equipped to copy the contents of the security key storageregister 112, 128, respectively, into the smart card reader network 106.The security key storage register 112, 128 is coupled to a first inputof a security key comparison device 110, 126, respectively. A secondinput of the security key comparison device 110, 126 is connected to asecurity key comparison input device 116, 122, respectively.

The security key comparison device 110, 126 is equipped to compare thefirst input with the second input, and to generate a signal at acomparison device output, such that the generated signal is based uponthe results of the comparison. If the first and second inputs areidentical, the security key comparison device 110, 126 generates a matchsignal at the comparison device output. If the first and second inputsare not identical, the security key comparison device 110, 126 generatesa no-match signal at the comparison device output.

The comparison device 110, 126 output is coupled to an electronicsecurity lock 108, 120, respectively. The security lock 108, 120 may beplaced into any one of two mutually-exclusive states. In a first, lockedstate, the security lock 108, 120 disables the smart card 102, 104 fromtransferring money to another smart card. In a second, unlocked state,the security lock 108, 120 permits money to be transferred to anothersmart card. The security lock 108, 120 is coupled to the output ofcomparison device 110, 126, respectively. When the comparison device110, 126 produces the match signal, the security lock 108, 120 is placedinto the second, unlocked state. The security lock 108, 120 is placedinto the first, locked state upon receipt of a no-match signal from thecomparison device 110, 126.

The functions of the electronic security lock 108, 120 and security keycomparison device 110, 126 may be implemented using a microprocessordevice of the type well-known to those skilled in the art and utilizedin various existing smart card designs. The functions of the securitykey storage register 112, 128 may be implemented using themicroprocessor described above, and/or such a register may be providedin the form of random-access memory (RAM). The security key registerinput device 118, 124, the security key comparison input device 116,122, and the security key register output device 114, 130 operate underthe control of the above-described microprocessor, and may beimplemented using conventional smart card data I/O devices which providefor the exchange of data between a smart card 102, 104 and a smart cardreader network 106. Conventional smart card data I/O devices and smartcards 102, 104 are well-known to those skilled in the art.

Smart card reader network 106 comprises a configuration of two or moreconventional smart card reader ports, such as a first smart card readerport 141 and a second smart card reader port 143. First and second smartcard reader ports 141, 143 are of the type well-known to those skilledin the art, to permit substantially concurrent exchange of data betweentwo smart cards 102, 104. First smart card reader port 141 may besituated at a remote location with respect to second smart card readerport 143. Accordingly, first and second smart card reader ports 141, 143are linked together over a communications link 150. In the case wheresmart card reader ports 141, 143 are widely-separated, thiscommunications link 150 may comprise modems communicating over aconventional telephone connection. Alternatively, smart card readerports 141, 143 may be integrated into a single structure and connectedusing a communications link 150 comprising, for example, simple wirepairs. First and second smart card reader ports 141, 143 may alsoinclude smart card holder input means, such as a keypad, to permit theentry of data such as PINs (personal identification numbers) by smartcard holders. These smart card reader ports 141, 143 include data inputmeans 149, 151 and data output means 145, 147, for, respectively,accepting data from, and providing data to, a smart card. The dataoutput means 145 of smart card reader port 141 is linked to the datainput means 151 of smart card reader port 143. Likewise, the data inputmeans 149 of smart card reader port 141 is linked to the data outputmeans 147 of smart card reader port 143.

The flow of data between smart card reader port 141 and smart cardreader port 143 may be controlled by an optional smart card readermicroprocessor internal to the smart card reader network 106. The smartcard reader microprocessor is of a type well-known to those skilled inthe art. If a smart card reader microprocessor is not used, themicroprocessors within the smart cards 102, 104 are employed to controlthe flow of data across smart card reader network 106.

To implement an exchange of money between two smart cards 102, 104, thesystem of FIG. 1 operates as follows. Assume that money is to betransferred from smart card 102 to smart card 104. Smart card 102 isinserted into smart card reader port 141, and smart card 104 is insertedinto smart card reader port 143. The microprocessor within smart card102 exchanges initial handshaking information with the microprocessor ofsmart card 104 to ascertain that both smart cards are communicatingacross the smart card reader network 106. Next, the security keyregister output device 114 of smart card 102 sends a signal representingan electronic security key to data input means 149 of smart card readernetwork 106. The security key is transferred to the data output means147, and conveyed to security key comparison input device 122 of smartcard 104.

The security key comparison device 126 retrieves the security key storedin security key storage register 128 on smart card 104. If thecomparison device 126 ascertains that the security key received fromsmart card 102 matches the security key stored in the security keystorage register 128, the electronic security lock 120 within smart card104 is unlocked to enable smart card 104 to participate in one or morefinancial transactions with smart card 102. If, however, the securitykey retrieved from security key storage register 128 does not match thesecurity key received from smart card 102, smart card 104 is disabledfrom participating in all financial transactions.

The security key comparison process implemented by smart card 104 isalso performed by smart card 102. Smart card 104 retrieves the securitykey stored in security key storage register 128 and conveys the securitykey to security key register output device 130. The security key isreceived by data input means 151 of smart card reader network 106, andsent to data output means 145. The security key is forwarded by dataoutput means 145 to security key comparison input device 116 of smartcard 102. Security key comparison input device 116 sends the securitykey to security key comparison device 110. Meanwhile, the security keystored in security key storage register 112 is sent to security keycomparison device 110, where the security key from storage register 112is compared with the security key received from smart card 104. If thesesecurity keys match, the security key comparison device 110 provides an"unlock" signal to electronic security lock 108 which unlocks thesecurity lock, permitting smart card 102 to participate in one or morefinancial transactions with smart card 104. If, however, the securitykeys do not match, comparison device 110 provides a "lock" signal toelectronic security lock 108. Electronic security lock 108 responds tothe lock signal by disabling smart card 102 from participating in anyfinancial transactions.

In the above-described example, the electronic security locks 108, 120of both smart cards 102, 104 must be unlocked in order to permit afinancial transaction to take place between these smart cards. If theabove-described exchange of security keys results in the locking of oneor both of the electronic security locks 108, 120, no financialtransactions can take place between smart cards 102 and 104.

The example set forth above assumes that each smart card 102, 104contains one security key in security key storage register 112, 128,respectively. However, the example of one security key was described forease of illustration. Any desired number of security keys may beemployed to meet the requirements of specific design applications.According to one embodiment set forth herein, each smart card 102, 104employs four security keys which are stored in security key storageregister 112, 128, respectively. Security key comparison device 110compares all four security keys stored in smart card 102 with all foursecurity keys received from smart card 104. Similarly, security keycomparison device 126 compares all four security keys stored in smartcard 104 with all four security keys received from smart card 102. If atleast two of the security keys match, the respective electronic securitylock 108, 120 is unblocked. If less than two of the four security keysmatch, the respective security lock 108, 120 is locked.

In the embodiment which utilizes four security keys per smart card, thesecurity keys can be updated and/or changed to provide improved systemsecurity. Bank smart cards are used to update/change the security keysstored in user smart cards. More particularly, assume for purposes ofthis illustration that smart card 102 is a bank smart card. Bank smartcards are equipped to retrieve a security key from the bank smart cardsecurity key storage register 112 and convey the key to the bank smartcard security key register output device 114 (user smart cards are alsoso equipped). The output device 114 sends the security key to data inputmeans 149 of smart card reader network 106, along with a bank smart cardsignal which serves to identify bank smart cards from all other types ofsmart cards, such as user smart cards.

The security key and the bank smart card signal are conveyed to dataoutput means 147. The microprocessor of smart card 104 recognizes thebank smart card signal at data output means 147 and, in response to thissignal, places the security key at data output means 147 into securitykey storage register. When the newly-received security key is placedinto security key storage register 128, it replaces one of thepreviously-existing security keys stored in register 128, it replacesone of the previously-existing smart cards and bank smart cards are usedto update/change one or more security keys in user smart cards. Thesecurity keys are changed from time to time to provide an enhancedmeasure of security. The keys can be changed periodically, i.e, atregular time intervals, or, alternatively, the keys may be changed atrandom time intervals, if desired.

The smart card money transfer system of FIG. 1 utilizes three types ofsoftware. These are exchange software, interest/key update software, andadministration software. Exchange software enables money to betransferred from one smart card to another. Interest/key softwareenables interest payments to be made to a smart card, and administrationsoftware enables the performance of various administrative functions.These administrative functions may include, for example, updating a filewhich lists and identifies all "bad" smart cards, and/or updating a filecontaining the current interest rate to be paid to specific smart cards."Bad" smart cards may include defective, failed, stolen, "foreign"(non-system) and/or counterfeit smart cards. A specially-designatedadministrative smart card may be used to perform the aforementionedadministrative function, in conjunction with a card reader and acomputer. This administrative card contains the hardware and datastructures of FIG. 1. All software is executable on conventionalpersonal computers, and/or on smart card reader software platforms whichcontain processing devices.

Some of the software used by the smart card money transfer system canreside on the smart cards 102, 104. If desired, this software can beplaced into a ROM device on the smart card. For example, three programsmay advantageously be placed onto the smart cards 102, 104. The firstsuch program is a routine entitled exch.ini and provides the datastructures and functions necessary to implement financial transactions.This program also enables the smart cards to receive electronic securitykeys and interest payments. This executable program preferably resideson all user smart cards, including bank center smart cards.

The second program which may reside on the smart cards 102, 104 isentitled int.exe, and provides the data structures and functionsnecessary to update electronic security keys. The program alsoimplements the process of giving interest to another bank smart card orto a user smart card such as a card held by a merchant or a consumer.The third routine which may be placed on a smart card is entitledissue.exe, and permits an administrative smart card to issue a bank oruser smart card.

The smart card money transfer system (FIG. 1) performs financialtransactions which involve, for example, the transferring of money fromone card to another. However, money is only "created" using aspecially-designated bank center smart card having hardware and datastructures as shown in FIG. 1. The "creation" of money refers to thefact that, in this case, money is put onto a smart card without takingmoney from another smart card. The same general concept holds true forelectronic security keys. These keys are loaded into bank center smartcards by a system administrator, and are then electronically transferredto other smart cards via card reader network 106.

The smart cards may be organized into a hierarchical structure. Forexample, the top level includes one or more bank center smart cards, thesecond level includes one or more bank region smart cards, at the thirdlevel are bank branch smart cards, and at the fourth level are the usersmart cards which include merchant smart cards and consumer smart cards.Security keys and interest payments flow down the hierarchical ladderfrom the top levels to the lower levels.

Security functions for the smart card financial transaction system areperformed by one or more electronic security keys. In addition to thesecurity keys, proprietary information may also be incorporated into thesystem to provide an enhanced level of security. However, security is arelative concept. Practically speaking, irrespective of the level oftechnical sophistication employed, there is no such thing as aninvulnerable security system. By way of example, it is certainlypossible for people to make their own dollar bills. However, the cost ishigh, and the penalty is great for getting caught. The security keys112, 114, 116 provide a measure of security analogous to that providedby the dollar bill, in terms of the aforementioned costs and penalties.

The security provided by security keys is such that all individualsinvolved in the implementation of security functions for the smart cardfinancial transaction system could leave the system, but none of theseindividuals would be able to break the system without detection andimmediate correction. To provide this level of security, it is notpossible to rely solely on proprietary information. However, proprietaryinformation is valuable in preventing attacks from outside individualswho were never affiliated with the security system. For this reason,proprietary information is combined with other forms of security toprovide an enhanced level of security not otherwise possible.

Security keys are provided in the form of four application keys storedon each smart card 102, 104. These application keys are stored asnumerical values in smart card 102, 104 memory. During each financialtransaction with a bank center smart card, the numerical value stored inone application key is updated. Two valid application keys are requiredto successfully implement a financial transaction. The application keysstored in a bank center smart card are updated from time to time, forexample, such that each application key is valid for one month. In thismanner, the maximum amount of time that a cardholder can go without abank transaction is three months. However, this number can be changed tomeet the needs of specific system requirements by adding moreapplication keys to each smart card, and/or by changing the amount oftime for which each application key numerical value is valid. The bankcould use eight keys and change one key per day. In this case, everysmart card holder would have to hold a financial transaction with thebank at least once per week. Although the application keys may beperiodically updated at regular time intervals, periodicity is notrequired. The application keys could be updated dynamically at irregulartime intervals.

To implement the application keys, each smart card 102, 104 may beequipped with a file called KEY₋₋ NUMBER. This file specifies numericalvalues corresponding to specific application keys. KEY₋₋ NUMBER alsostores the most recent date for which a key was updated. For example,the application key numerical values may be changed once per month, withnumerical values 51, 52, 53, and 54 corresponding to months 51 through54, respectively.

For two smart cards 102, 104 to implement a successful transfer ofmoney, these smart cards must have at least two identical applicationkeys. If smart card 102 contains application keys of 49, 50, 51, and 52,whereas smart card 104 contains application keys of 51, 52, 53, and 54,the money transfer can be successfully implemented, due to the presenceof two identical keys--namely, 51 and 52. However, if the applicationkeys of smart card 102 are 51, 52, 53, and 54 whereas the applicationkeys of smart card 104 are 54, 55, 56, and 57, it would not be possibleto implement a successful money transfer between these two smart cards102, 104.

Each user smart card 102, 104 is assigned an account number of 16 digits(8 bytes). One or more of the smart cards 102, 104 may become lost orstolen. Such cards are known as "bad" cards, and are not allowed toreceive application key updates. Bank smart cards corresponding to eachlevel in the smart card bank hierarchy mentioned above may be 8K smartcards equipped to store account numbers for up to 600 bad cards.Assuming that up to 10% of the user smart cards 102, 104 in a givensystem become lost or stolen (this figure conforms to the credit cardindustry norm), then one bank center smart card can manage a pool of6000 user smart cards.

Managing a pool of 6000 user smart cards 102, 104 can be performed atthe bank region hierarchical level. In this manner, one or more specificapplication key updates are limited to a predetermined section ofaccount numbers, e.g., 40000 to 46000, such that these account numberscorrespond to smart cards serviced by a given bank region, and/or agiven branch bank. To improve upon this branch bank scenario, it may beassumed that each bank branch only handles smart cards with accountnumbers in a certain range. If this assumption holds true, then onlyfour bytes (the last four digits) of the account numbers need to bestored at the bank branch level.

Techniques for managing bad smart cards are important, because theeffectiveness of these techniques can determine the overallprofitability or loss of a given smart card system. If smart card systemoperators are careless, and if inadequate bad card management techniquesare employed, the operator may end up losing more money per customerthan it is possible to recover.

After the keys on a bad card expire, the card can be removed from thebad card list. Therefore, a bank branch card can store 1200 bad cardnumbers and manage a pool of 24,000 user cards, assuming that only 5% ofthe user smart cards are on the bad card list any one time.

If no more than 10% of the user smart cards corresponding to aparticular bank branch will ever be stolen, then the next hierarchicallevel (say the "bank region") would be able to handle 6,000 bank branchsmart cards. The total number of customers in this scenario can thus be144 MILLION. Because it may be desirable to provide larger total systemcapacity, another hierarchical level may be used, termed "bank center".The bank center smart card 103 can handle up to 6,000 bank region cards,and thus provide plenty of total system capacity.

With respect to smart card update time, assume that it takes 10 seconds(maximum) to update a smart card. Further assume that 24,000 people wantto update their keys in that one hour. The system must have theequivalent of 24 bank branch smart cards working full time. If the bankbranch smart cards are duplicated, each of these cards is issued adifferent account number so that the generation process can be performedand managed by a smart card. A given smart card account number shouldnever be issued more than once. Therefore, taking this reduction intoaccount, the maximum number of user smart cards 102, 104 in a region is6 million. Because the bank branch cards can be assigned update times,bank region cards need not be duplicated.

All security keys are generated by a bank center smart card which hasthe structure of smart card 102 and further includes a random numbergenerator. The security key storage register of the bank center smartcard is loaded with the security keys necessary to generate and updateall other smart cards. After the original card issuing process, this ishow security key updates proceed. A command is sent to the bank centercard to update its date and security keys. The bank center cardgenerates a new security key using its random number generator andupdates a first application key corresponding to this new security keyand increments the KEY₋₋ NUMBER file. The KEY₋₋ NUMBER file is updatedwith a new date. A new interest rate can also be loaded into the bankcenter smart card at this time.

After the bank center smart card updates its security keys, it hasscheduled transactions with all of the bank region smart cards in orderto update their security keys. The bank region smart cards then updatethe bank branch smart cards. And finally the bank smart branch cardsupdate the user smart cards.

In general, money can only be added to one smart card when it is takenaway from another smart card. The exception to this is the bank centersmart card. A bank center card key exists which contains key valuesmatching the application key values stored in the bank center smartcard. Whoever holds this key can create money by updating this card'sbalance file. This person cannot read the application keys on the bankcenter card. To get this money down the pyramid of cards from the bankcenter smart card to the user smart cards 102, 104, a bank regioncardholder would request a transfer of say $1 million card dollars inexchange for a like transfer of money in another form. Approval is givenby the bank center cardholder typing in the correct key (most likely adifferent key than that used to create money). This money goes down thepyramid of cards until it reaches the cardholders themselves. If theapplication is growing, then the flow of card money should be down andthe flow of other money should be up. For example, in a card moneyexchange involving two smart cards, smart card 102 and smart card 104,the cards smart card 102 and smart card 104 may be any of the cardsspecified in FIG. 2. For a given pair of cards smart card 102 and smartcard 104, FIG. 2 describes the nature of the financial transaction whichmay take place.

Financial transaction flow will now be described. These transactions arecapable of being performed over a remove link. The transactions alwaystake place between two cards. Smart card readers and PC software servemerely to connect the cards and provide user input. A conventional smartcard reader is used at both ends of the link, each sender having akeypad for PIN or key input (similar to an ATM or Telephone Adapter withsmall keypad). These readers are well-known to those skilled in the art.

The financial transaction proceeds as indicated in FIG. 3. First, inblock 301, smart card 102 (a first smart card) is inserted into firstsmart card reader port 141 (a first smart card reader). Next, thecardholder corresponding to the first smart card smart card 102 dialsthe telephone number (if the reader includes a Telephone Adapter) orchooses the correct menu item (if using an ATM or PC-based card reader)to dial up a host computer and/or another Telephone Adapter (block 302).

At block 303, a second smart card, smart card 104, is inserted intosecond smart card reader port 143 (a second smart card reader). Thensmart card 102's cardholder enters "EXCH" or equivalent code into thereader first smart card reader port 141 keypad (block 304).

At block 305, first smart card reader port 141 prompts for informationneeded to complete the financial transaction. This information mayinclude:

a. Credit/Debit/Interest

b. Amount of Money to be Transferred

c. Card PIN or Security Key Numerical Value

Then, first smart card reader port 141 lends a data packet to secondsmart card reader port 143 detailing the financial transaction (block306).

At block 307, second smart card reader port 143 prompts the cardholdercorresponding to smart card 104 for information needed to complete thefinancial transaction. This information may include:

a. Credit/Debit/Interest

b. Amount of Money to be Transferred

c. Card PIN or Security Key Numerical Value

At block 308, second smart card reader port 143 sends a data packetdetailing the financial transaction to first smart card reader port 141.If the data packets sent in blocks 306 and 308 are identical, then thecard reader specified by the following table begins the transaction bysending a security key numerical value. Therefore it does not matterwhich cardholder begins the transaction; from this point on it follows astandard flow based on the transaction type.

    ______________________________________    Financial Transaction                      First Reader    ______________________________________    Smart card 102 sends card                      second smart card reader port 143    money to smart card 104    Smart card 102 receives card                      first smart card reader port 141    money from smart card 104    Smart card 102 receives interest                      first smart card reader port 141    & security keys from smart card 104    Smart card 102 sends interest &                      second smart card reader port 143    security keys to smart card 104    ______________________________________

The following sections detail the first and last financial transactionlisted in the above table. The remaining two financial transactions arethe same if smart card 102 and smart card 104 are switched.

FIGS. 4A and 4B describe the steps of a cardholder-to-cardholdertransaction. Smart card 102 stands for card 1 and is the card of theperson "spending the money". At block 401, smart card 102 is insertedand a card PIN is verified (this verification substep is optional fortransactions less than an amount stored in a MIN₋₋ TRANS file). Next,smart card 104 is inserted and PIN verified (this verification substepis optional for all cases) (block 402). At block 403, second smart cardreader port 143 executes smart card 104's C₋₋ EXCH.EXE program describedpreviously, with input variables specifying a credit and an amount A1.smart card 104 responds with the security key number of its first key.Then, second smart card reader port 143 sends this security key numberto first smart card reader port 141 (block 404).

First smart card reader port 141 executes smart card 102's C₋₋ EXCH.EXEprogram with input variables specifying debit, amount (A1) and smartcard 104's key number. Smart card 102 responds with a key number equalto smart card 104's first, second, or third security keys. If none ofthe key numbers in smart card 102 and smart card 104 match, then smartcard 102 cannot work with the proposed key set of smart card 104, andsmart card 102 aborts the transaction and updates the BAD₋₋ KEY file(block 405). At block 406, first smart card reader port 141 sends aresponse to second smart card reader port 143. Second smart card readerport 143 sends the key number response to smart card 104. This keybecomes the first security key (APPKEY0, or AK0 for short) for the restof the transaction (block 407). Smart card 102 continues response withpacket 1 (P1) encrypted in APPKEY0 (AK0). This acts as a challenge tosmart card 104. Smart card 102 also updates it PASSBOOK file (block408). First smart card reader port 141 sends this packet to second smartcard reader port 143 (block 409). Smart card 104 responds with packet 2(P2) encrypted in AK0. This is the response to the challenge and smartcard 102 checks to make sure that the third field (public name) his beenchanged from P1 and is a valid name (contains only ASCII characters in acertain range). Smart card 104 also updates its PASSBOOK file (block410). Second smart card reader port 143 sends this packet to first smartcard reader port 141 (block 411). Smart card 104 continues response withpacket 3 (P3) encrypted in APPKEY1 (AK1). This acts as a challenge tosmart card 102 (block 412). Second smart card reader port 143 sends thispacket to first smart card reader port 141 (block 413). Smart card 102debits the amount from the card balance and updates the PASSBOOK file(block 414). Smart card 102 responds with packet 4 (P4) encrypted inAK1. This is the response to the challenge and smart card 104 checks tomake sure that the third field (credit amount) has been changed from P3to P4 and is a valid field (contains the correct credit code which isdifferent from the debit code and contains the same amount as in P3). Ifthese fields are not correct, the BAD₋₋ KEY file gets updated (block415). First smart card reader port 141 sends this packet second smartcard reader port 143 (block 416). Smart card 104 credits the amount toits card balance and updates the PASSBOOK file (block 417).

Security key update and interest transactions will be described withreference to FIGS. 5A and 5B. These are transactions between a user cardand a bank branch card (or equivalently the branch and region card orthe region and center card). The following describes the steps of acardholder-to-bank-branch transaction. Smart card 102 stands for card 1and is the card of the person "spending the money", in this case thebank branch. Smart card 104 stands for card 2 and is the card of theperson "receiving the money", in this case the cardholder. Somewhereduring this transaction the PASSBOOK file of smart card 104 needs to beread, stored and cleared.

Block 501: smart card 102 inserted and Verify PIN. This step is theequivalent of someone at the bank "loading" the bank branch card into acard reader. Block 502: smart card 104 inserted and Verify PIN. Thisstep assures that the proper cardholder still has the card and issimilar to using your current card at an ATM (you can be photographed tolater prove that it was you). Block 503: second smart card reader port143 executes smart card 104's C₋₋ EXCH.EXE with argument 2 (receiveinterest). Smart card 104 responds with the key number of its APPKEY0 (0to 255). Block 504: second smart card reader port 143 sends the keynumber to first smart card reader port 141. Block 505: first smart cardreader port 141 executes smart card 102's C₋₋ INT.EXE with argument 3(give interest) and smart card 104's key number. Smart card 102 respondswith a key number equal to smart card 104's APPKEY0, APPKEY1 or APPKEY2.If smart card 102 cannot work with the proposed key set, then it abortsthe transaction and sets up an expired key file transaction. Block 506:first smart card reader port 141 sends response to second smart cardreader port 143. Block 507: second smart card reader port 143 sends thekey number response to smart card 104. This key becomes APPKEY0 for therest of the transaction. Block 508: smart card 102 continues responsewith packet 1 (P1) encrypted in APPKEY0 (AK0). This acts as a challengeto smart card 104. Smart card 102 also updates its PASSBOOK file. Block509: first smart card reader port 141 sends this packet to second smartcard reader port 143. Block 510: smart card 104 responds with packet 2(P2) encrypted in AK0. This is the response to the challenge and smartcard 102 checks to make sure that the third field (public name) has beenchanged from P1 and is a valid name (contains only ASCII characters in acertain range). Smart card 104 also updates its PASSBOOK file. Block511: second smart card reader port 143 sends this packet to first smartcard reader port 141. Block 512: smart card 104 continues response withpacket 5 (P5) encrypted in APPKEY1 (AK1). This acts as a challenge tosmart card reader port 141. Block 514: smart card 102 checks to makesure that the third field (balance) has a valid checksum and a logicaldate and interest rate. It also checks the fourth field (account number)versus its BAD₋₋ CARD file. (If it finds the number in the BAD₋₋ CARDfile it initiates an invalidate card transaction.) Using its date file,it calculates the amount of interest to credit to smart card 104, debitsthe amount from smart card 102's card balance and updates its PASSBOOKfile. Smart card 102 also looks to see if smart card 104 needs a new keyand, if so, supplies one in P6. Block 515: smart card 102 responds withpacket 6 (P6) encrypted in AK1. This is the response to the challengeand smart card 104 checks to make sure that the third through fifthfields have been changed from P5 and are valid. Block 516: first smartcard reader port 141 sends this packet to second smart card reader port143. Block 517: smart card 104 credits the amount to its card balance,changes the date and updates the interest rate if necessary. If a newkey is included in the fifth field, it updates its application keys byreplacing the oldest (APPKEY0) with the new one and incrementing thenumber in the KEY₋₋ NUMBER file. It also updates the PASSBOOK file.

The data packets shown in FIG. 6 may be transferred from a first smartcard to a second smart card during a financial transaction. Packet 1contains the following fields and information: Field 601: Random Number.The first field is an eight byte random number generated by smart card102. Field 602: Application Number. The second field is the eight byteapplication ID number that is the same for all cardholder cards. Field603: Public Name. The third field is an eight byte ASCII name ofcardholder smart card 102. Field 604: Account Number or Signature. Thefourth field is either an eight byte signature of the first three fieldsgenerated by smart card 102 using the card's APPKEY0 or just smart card102's account number if privacy is not desired. These four fields aremixed (two bytes at a time from each field) and encrypted in an APPKEY0and sent from smart card 102 to smart card 104.

Packet 2 contains the following fields and information: Field 611:Random Number. The first field is the eight byte random number that wasgenerated by smart card 102 and received in packet 1. Field 612:Application Number. The second field is the eight byte application IDnumber that is the same for all cardholder cards. Field 613: PublicName. The third field is an eight byte ASCII name of cardholder smartcard 104. Field 614: Account Number or Signature. The fourth field iseither an eight byte signature of the first three fields generated bysmart card 104 using the card's key 0 or just smart card 104's accountnumber if privacy is not desired. These four fields are mixed (two bytesat a time from each field) and encrypted in an APPKEY0 and sent fromsmart card 104 to smart card 102.

Packet 3 contains the following fields and information: Field 621:Random Number. The first field is an eight byte random number that isgenerated by smart card 104. Field 622: Application Number. The secondfield is the eight byte application ID number that is the same for allcardholder cards. Field 623: Debit Amount. The third field is the amountto be debited from smart card 102's balance file. Field 624: AccountNumber or Signature. The fourth field is either an eight byte signatureof the first three fields generated by smart card 104 using the card'skey 0 or just smart card 104's account number if privacy is not desired.These four fields are mixed (two bytes at a time from each field) andencrypted in an APPKEY1 and sent from smart card 104 to smart card 102.

Packet 4 contains the following fields and information: Field 631:Random Number. The first field is the eight byte random number that wasgenerated by smart card 104 and received in packet 3. Field 632:Application Number. The second field is the eight byte application IDnumber that is the same for all cardholder cards. Field 633: CreditAmount. The third field is the amount to be credited to smart card 104'sbalance file. Field 634: Account Number or Signature. The fourth fieldis either an eight byte signature of the first three fields generated bysmart card 102 using the card's key 0 or just smart card 102's accountnumber if privacy is not desired. These four fields are mixed (two bytesat a time from each field) and encrypted in an APPKEY1 and sent fromsmart card 102 to smart card 104.

Packet 5 contains the following fields and information: Field 641:Random Number. The first field is the eight byte random number that wasgenerated by smart card 102 and received in packet 1. Field 642:Application Number. The second field is the eight byte application IDnumber that is the same for all cardholder cards. Field 643: Balance.The third field contains smart card 104's balance file and is 24 byteslong. Field 644: Account Number or Signature. The fourth field is eitheran eight byte signature of the first three fields generated by smartcard 104 using the card's key 0 (AK0) or just smart card 104's accountnumber if privacy is not desired. These four fields are mixed into 6groups of 8 bytes and encrypted in an APPKEY0 and sent from smart card104 to smart card 102.

Packet 6 contains the following fields and information: Field 651:Random Number. The first field is the eight byte random number that wasgenerated by smart card 104 and received in packet 5. Field 652:Application Number. The second field is the eight byte application IDnumber that is the same for all cardholder cards. Field 653: CreditAmount. The third field is the amount to be credited to smart card 104'sBALANCE file. Field 654: Date. The fourth field is the new date andinterest rate for smart card 104's BALANCE file. Field 655: NewApplication Key. The fifth field is 8 bytes long and contains a newapplication key if smart card 104 does not have the latest key. Field656. Account Number or Signature. The sixth field is smart card 102'saccount number because privacy and interest are mutually exclusive.These six fields are mixed into 6 groups of 8 bytes and encrypted in anAPPKEY1 and sent from smart card 102 to smart card 104.

BALANCE 703. This file contains the balance amount of the card, thecurrency of the balance, the last date interest was logged, the serialnumber of the currency and the balance checksum. The balance amount is 4bytes long with 6 bits of each byte used to store value and 2 bits usedas checksums. The currency of the balance is 1 byte long with adifferent code for each currency. The date of last interest is 4 byteslong with 2 digits for month, 2 digits for day and 4 digits for year.The interest rate is 3 bytes long. The serial number of the currency is4 bytes long and represents a number unique to the card (possibly theaccount number encrypted with a master key). The balance checksum is 8bytes long and represents the first 8 bytes of the file encrypted by thesecond 8 bytes of the file and then encrypted by a master key. Thus thebalance file is 24 bytes long.

APPKEY0 704 through APPKEY3 707. These files contain the fourapplication keys, each 8 bytes long. PASSBOOK 708. This file containsthe audit trail similar to a passbook savings account. Each entry is 36bytes long and a total of 50 entries can be stored. Each entry includesthe account number of the other party (or the signature if privacy isdesired) (8 bytes), the public name of the other party (8 bytes), therandom number generated by the other card (8 bytes), the date if known(4 bytes), credit or debit or interest (1 byte), the transaction amount(3 bytes) and the new account balance (4 bytes). The total size of thisfile is 1800 bytes. This file is downloaded to the bank on valid banktransactions unless privacy is desired. If larger files are needed formerchant user cards, 8K cards can be provided and the PASSBOOK file canbe greatly expanded.

KEY₁₃ INFO 709. This file stores the current APPKEY number and the lastdate that the keys were updated by the bank. It is 5 bytes (1 for thenumber and 4 for the date) long. BAD₋₋ KEY 710. This file stores thenumber of bad key attempts and is 2 bytes long. It gets reset after avalid bank transaction. When this number reaches a set limit, the cardis locked. MIN₋₋ TRANS 711. This file stores the transaction amountabove which a PIN is required. This file is 3 bytes long. MAX₋₋ TRANS712. This file stores the transaction amount above which a key isrequired. This file is 4 bytes long. RANDOM₋₋ NUMBER 713. This filecontains the random number seed to ensure that the numbers are notrepeated in any predictable pattern. If the executable file is 700 byteslong (the same as TCAs), the total space needed on the card would beabout 2,700 bytes.

In addition to the files discussed above, each bank smart card containsthe following additional files: BAD₋₋ CARD 714. This file stores a listof 4-byte account numbers that are bad cards. It can store a total of1,200 numbers for a total tile size of 4,800 bytes. VALID ACCOUNT 715.This file stores the highest and lowest valid account numbers for cardsthat can receive key updates. It is 32 bytes long. C₋₋ INT.EXE 716. Thisexecutable file enables the card to give interest and update keys.INTEREST 717. This file stores the daily interest rate and is 4 byteslong.

With respect to system fraud and fraud prevention, if the smart cardsystem operator has money, defrauders will exist. Defrauders are peoplewho would like to take some of the system operator's money away.Possible methods of attack and countermeasures will now be described.ATTACK #1. Trying to put money on one card without taking money fromanother card. To do this, a packet of data must be sent to the card,containing the correct information for a credit. There are threepossible means of attack: A. Replay attacks, which will not work becauseeach packet contains a unique random number. The system operator mustmake sure that each card starts with a different random number seed andcannot be reset to its original seed in any way. Since none of therandom numbers are ever sent in clear text, this offers some protection.B. Random attempts at sending packets to the card, which will not workbecause, after so many guesses, the BAD₋₋ KEY file will cause the cardto lock. This is really the equivalent of trying to guess the key. C.Direct key attack. Under the implementation described above, thedefrauder would get a good packet and try to decrypt it with random keysuntil getting a valid application number. This takes an average of twodecryptions per packet and 263 different keys for expected success or584 years at 1 billion encryptions per second. This is directly relatedto the security of DES and is what security is based on. Doubleencryption may be used in risk-prone environments at the expense ofslowing the transaction and attack times down.

ATTACK #2. Stealing a valid card. All cards are protected by PINs forsmall transactions and can be key protected for larger transactions. Thethief could use the card for transactions under the MIN₋₋ TRANS filelimit, but the next time interest/key update occurred, the card would beinvalidated. The invalidation process could also happen at point of saleterminals for large purchases if there was fear about PINs or keys beingstolen from the cardholder. If the thief attempts to convert the cardmoney into cash (buying cash rather than goods) perhaps by trading withanother cardholder), then the thief must have the PIN or key or belimited by the number of transactions stored in the PASSBOOK file (50).Therefore, if the user does not lose their PIN, the maximum expectedloss is $250 (if the MIN₋₋ TRANS file is set at $5 and no transactionsare stored in the PASSBOOK file). This loss can be sent to zero byreducing the number in the MIN₋₋ TRANS file to zero. If the PIN is lost,then the amount at risk is potentially 50 times the MAX₋₋ TRANS file orthe amount stored on the card. IF MAX₋₋ TRANS is set at $100, thenpotentially $5K is at risk. Thus this card is more like cash than anormal credit card and needs to be treated more carefully than a normalcredit card.

It is to be understood that the above-described embodiments are merelyillustrative principles of the invention and that many variations may bedevised by those skilled in the art without departing from the scope ofthe invention. It is therefore intended that such variations be includedwithin the scope of the following claims.

What is claimed:
 1. A method of providing secure smart card transactionsin a system having a smart card hierarchy, the hierarchy including atleast a first smart card at a first hierarchical level and a secondsmart card at a second hierarchical level higher than the firsthierarchical level, and a smart card reader for reading smart cards andfor accepting personal identification (PIN) number inputs, the methodincluding the steps of:storing a first PIN number on the first smartcard, the first PIN number corresponding to the first hierarchicallevel; storing a first security key on the first smart card; storing asecond PIN number on the second smart card, the second PIN numbercorresponding to the second hierarchical level; and storing a secondsecurity key on the second smart card.
 2. The method of claim 1 furtherincluding the steps of:(a) comparing the PIN number stored on the firstsmart card with a PIN number entered into the smart card reader; (b)comparing the first security key with the second security key; and (c)enabling the first smart card if the PIN numbers compared in step (a)are an identical match and if the first and second security keyscompared in step (b) are an identical match; otherwise, disabling thefirst smart card.
 3. The method of claim 1 for use with a smart cardreader equipped with a personal identification number input device,wherein the method further includes the following steps:(a) storingelectronic representations of monetary values on a plurality of smartcards organized into the smart card hierarchy, (b) equipping each of thefirst smart card and the second smart card with an electronic securitylock for providing system security, the security lock having a lockedstate such that the smart card is disabled from participating in atleast one financial transaction, and an unlocked state such that thesmart card may participate in at least one financial transaction; (c)equipping the first smart card with a first plurality of security keysand a personal identification (PIN) number, and equipping the secondsmart card with a second plurality of security keys; (d) comparing thefirst plurality of security keys to the second plurality of securitykeys, and also comparing the PIN number to a number entered into thesmart card reader, to generate a match signal only if both (i) at leastone of the first plurality of security keys matches at least one of thesecond plurality of security keys and (ii) the PIN number matches thenumber entered into the smart card reader; and to generate a no-matchsignal otherwise; the electronic security lock being responsive to thematch signal to enter the unlocked state, and the electronic securitylock being responsive to the no-match signal to enter the locked state.4. The method of claim 1 for use with a smart card reader equipped witha personal identification number input device, the method furtherincluding the following steps:(a) equipping each of the first smart cardand the second smart card with an electronic security lock for providingsystem security, the security lock having a locked state such that thesmart card is disabled from participating in at least one financialtransaction, and an unlocked state such that the smart card mayparticipate in at least one financial transaction; (b) equipping thefirst smart card with a first plurality of security keys and a firstpersonal identification (PIN) number, and equipping the second smartcard with a second plurality of security keys and a second PIN number;(c) comparing the first plurality of security keys to the secondplurality of security keys, comparing the first PIN number to a numberentered into the smart card reader and comparing the second PIN numberto a number entered into the smart card reader, to generate a matchsignal if and only if (i) at least one of the first plurality ofsecurity keys matches at least one of the second plurality of securitykeys, (ii) the first PIN number matches a number entered into the smartcard reader; and (iii) the second PIN number matches a number enteredinto the smart card reader; and to generate a no-match signal otherwise;the electronic security lock being responsive to the match signal toenter the unlocked state, and the electronic security lock beingresponsive to the no-match signal to enter the locked state.
 5. A systemfor providing secure smart card transactions comprising a first smartcard, a second smart card, and a smart card reader for reading smartcards and for accepting personal identification (PIN) number inputs; thesystem CHARACTERIZED BY:a smart card hierarchy, the hierarchy includingat least a first smart card at a first hierarchical level and a secondsmart card at a second hierarchical level higher than the firsthierarchical level; a first PIN number stored on the first smart card;the first PIN number corresponding to the first hierarchical level; asecond PIN number stored on the second smart card; the second PIN numbercorresponding to the second hierarchical level; a first security keystored on the first smart card; and a second security key stored on thesecond smart card.
 6. The system of claim 5 further CHARACTERIZED BY:(a)a comparison device for comparing the PIN number stored on the firstsmart card with a PIN number entered into the smart card reader; andalso for comparing the first security key with the second security key;and (b) an enabling device, coupled to the comparison device, forenabling the first smart card if and only if the comparison devicedetermines (i) that the PIN number stored on the first smart cardmatches the PIN number entered into the smart card reader; and (ii) thatthe first and second security keys are an identical match.
 7. The systemof claim 5 for use with a smart card reader equipped with a personalidentification number input device;wherein the first and second smartcards each include an electronic security lock for providing systemsecurity, the security lock having a locked state such that the smartcard is disabled from participating in at least one financialtransaction, and an unlocked state such that the smart card mayparticipate in at least one financial transaction; the first smart cardmemory means equipped to store a first plurality of security keys and apersonal identification (PIN) number, and the second smart card memorymeans equipped to store a second plurality of security keys; the smartcard reader including comparison means for comparing the first pluralityof security keys to the second plurality of security keys, and also forcomparing the PIN number to a number entered into the smart card reader,to generate a match signal only if both (i) at least one of the firstplurality of security keys matches at least one of the second pluralityof security keys and (ii) the PIN number matches the number entered intothe smart card reader; and to generate a no-match signal otherwise; theelectronic security lock of the first smart card being responsive to thematch signal to enter the unlocked state, and the electronic securitylock being responsive to the no-match signal to enter the locked state.8. The system of claim 5 for use with a smart card reader equipped witha personal identification number input device, the system furtherincluding a plurality of smart cards each equipped to store electronicrepresentations of monetary values,the first smart card and the secondsmart card each including an electronic security lock for providingsystem security, the security lock having a locked state such that thesmart card is disabled from participating in at least one financialtransaction, and an unlocked state such that the smart card mayparticipate in at least one financial transaction; the first smart cardbeing equipped with a first plurality of security keys and a firstpersonal identification (PIN) number, and the second smart card beingequipped with a second plurality of security keys and a second PINnumber; the smart card reader including a comparison device forcomparing the first plurality of security keys to the second pluralityof security keys, for comparing the first PIN number to a number enteredinto the smart card reader, and for comparing the second PIN number to anumber entered into the smart card reader, the comparison device beingequipped to generate a match signal if and only if (i) at least one ofthe first plurality of security keys matches at least one of the secondplurality of security keys, (ii) the first PIN number matches a numberentered into the smart card reader; and (iii) the second PIN numbermatches a number entered into the smart card reader; and to generate ano-match signal otherwise; the electronic security lock being responsiveto the match signal to enter the unlocked state, and the electronicsecurity lock being responsive to the no-match signal to enter thelocked state.